Multiple address hyperlinks

ABSTRACT

A form of hyperlink is provided comprising a first component identifying a network entity and a scheme by which to communicate with that entity, and a second component comprising a further scheme and further address by means of which to access a resource relative to the network entity identified by the first component. Such hyperlinks support simple and fast sharing of files and, in some cases, support tunnelling through firewalls to achieve this. The invention also provides related data representations, electronic documents, protocols, signals, methods, devices, systems and other apparatus, and programs for computers.

FIELD OF THE INVENTION

The present invention relates to data addressing and access methods andapparatus, signals, programs for a computer, related data structures andtheir representations along with systems incorporating the same.

In particular, the present invention relates to, but is not restrictedto, improvements related to hyperlinks for use in distributedcomputerised networks.

BACKGROUND TO THE INVENTION

Recent computer-based systems have been directed to providing supportfor rapid creation of simple web pages by users of minimal skill. Suchsystems are sometimes known as “Wikis” (from the Hawaiian expression“wiki wiki” meaning “fast”). Many such systems however provide usersonly with a text-based user interface, which limits their adoption byless skilled users. Some wikis therefore provide a so-called What YouSee Is What you Get (WYSIWYG) interface in an attempt to make suchsystems accessible to a wider user base.

Wikis may be used to create personal wikis: local “webs” for personaluse, for example on a user's own personal computer, and in which many ofthe links may be made to local resources (e.g. files) rather than toremote resources using for example the Hypertext Transfer Protocol(HTTP). The ability to create such local web structures quickly andeasily allows users to organise their own files in novel ways, byconstructing local web pages which comprise hyperlinks to local files,and to determine their own page access and control policies.

However a problem with such systems is that, whilst such local web pagesmay be sent to other users, the local hyperlinks embedded within thosepages are not effective on remote host computers, or indeed whenselected by other users on the same computer, since they identify theresource locally relative to the creating user's local work space.

Peer-to-peer (P2P) computing is a model of distributed computing whichdoes not distinguish between client and server computers (or softwareentities on computers), so that every computer (referred to as a peer)may act either as a client or as a server or as both. Related peers maybe grouped together to form peer groups. The peer-to-peer paradigm istherefore quite distinct from the conventional client-server model ofweb-based applications in which servers provide services to clients butnot vice versa. P2P computing is also characterised by the way in whichcomputers are identified, and by the decentralised way in which computeridentifiers are used to determine the mechanism by which one computercommunicates with one or more other computers. This gives P2P computingan ability to traverse firewalls and accommodate Networks AddressTranslation (NAT) and the use of Dynamic Host Configuration Protocol(DHCP). Other known P2P frameworks (for example JXTA) use Relay andRendezvous peers to achieve this.

P2P computing is often associated with file-sharing applications (suchas Gnutella, Napster, WinMX® and Fileutopia) and Instant Messaging (IM).

Use of Asynchronous Pluggable Protocols within systems such as MicrosoftWindows® gives users the ability to integrate new functionality withinexisting systems by substituting new protocols for existing ones. Suchsubstitutions can be effected in such a way that almost any Windowsapplication can subsequently make use of the new functionality. Inparticular, Windows provides an Asynchronous Pluggable Protocol (APP) tosupport interpretation of the Hypertext Transfer Protocol (HTTP) UniformResource Locator (URL) scheme used to reference remote resources on theweb. Changes made to the HTTP URL scheme may therefore be implemented bysubstituting an amended HTTP APP. Remote resources referenced byhyperlinks are subsequently automatically accessed using the amendedprotocol from any application having links to a web page.

An example of how known web-based access systems operate is illustratedin FIG. 1. Server 10 comprises a file store 103 which containsweb-accessible files 1030 and non-web-accessible files 1031. Localclients 104 (typically supporting local users) access files 1040 (forexample web pages, spreadsheets, or text files) comprising one or morehyperlinks. These may take the known forms of HTTP URLs (“http:// . . .”) 1041 or File URLs (file:// . . . ) 1042.

Such URLs are interpreted locally with reference to the local filemanagement 103 or HTTP-client software. File-URLs result in directaccess of locally stored file, including both web-accessible files 1030and non-web-accessible files. HTTP-URLs result in access of theindicated file via a local HTTP client: the HTTP client determineswhether the file is local or remote and accesses the web-accessiblelocal file 1030 or a remote server accordingly.

A remote client 11 may also resolve URLs 1141 in locally accessibledocuments 114 but in that case the only URLs which resolve to a file onServer 10 are those which are HTTP-URLs. Typically such URLs may alsorefer to files on other servers 12.

A problem with this approach is that if a user on server 10 wishes tomake a file available over the web to another (possibly remote) user,the file must first be copied or moved into the local web-accessiblefile area 1030 since there is no mechanism by which a remote user 11 canaccess the non-web-accessible files 1031 over the web.

A further problem is that if a first user is located within a firstnaming domain and wishes to make a file accessible to a second user in asecond, different naming domain, then this is not easily achieved sinceresolution of the file address known to the first user in the seconduser's domain may not be successful. It is therefore desirable, at leastin some cases, to provide means by which users my readily share files insuch circumstances.

OBJECT OF THE INVENTION

The present invention seeks to mitigate at least one problem associatedwith the prior art.

SUMMARY OF THE INVENTION

The invention is directed to data representations, apparatus, andcomputer programs which comprise, refer to, or make use of novel networkresource addresses and methods of using them.

According to a first aspect of the present invention there is provided acomputer-readable representation of a hyperlink address comprising afirst portion comprising identification of a host and a first accessscheme for interacting with that host and a second portion comprising afurther hyperlink address comprising a second access scheme.

The further hyperlink address may be a Uniform Resource Locator.

The further hyperlink address may itself be a hyperlink address so thatthe second portion itself has a first and second portion.

The first access scheme may be a peer-to-peer access scheme.

The second access scheme may denote a HyperText Transfer Protocol (HTTP)

The second access scheme may be a local file access scheme.

According to a further aspect of the present invention there is provideda method of resolving a computer-readable representation of a hyperlinkaddress according to the first aspect on a given host, the methodcomprising: resolving the first portion to identify a host upon which toresolve the second portion; if the host is the local host resolving thesecond portion locally; if the host is not the local host, communicatingthe second portion to the host, by means of the first access scheme, forresolution of the second portion by the host.

According to a further aspect of the present invention there is providedan electronic document comprising a computer-readable representation ofa hyperlink address according to the first aspect.

The invention also provides for programs for computers in amachine-readable form and arranged, in operation, to carry out everyfunction of the apparatus and/or methods. In this context this isunderstood to include source and executable code and other formsincluding, but not limited to, code intended for or suitable forcompilation to hardware layouts, or programming of re-configurablehardware such as Field Programmable Gate Arrays (FPGAs).

In particular, according to a further aspect of the present inventionthere is provided a program for a computer arranged to create acomputer-readable representation of a hyperlink address according to thefirst aspect.

The program for a computer may comprise an editor comprising a graphicaluser interface and arranged to facilitate insertion of acomputer-readable representation of a hyperlink address by means of adrag-and-drop user interface.

According to a further aspect of the present invention there is provideda computer system arranged to create a computer-readable representationof a hyperlink address according to the first aspect.

According to a further aspect of the present invention there is provideda program for a computer arranged to parse a computer-readablerepresentation of a hyperlink address according to the first aspect.

According to a further aspect of the present invention there is provideda computer system arranged to parse a computer-readable representationof a hyperlink address according to the first aspect.

The invention is also directed to signals employed by the other aspectsof the invention.

In particular, according to a further aspect of the present inventionthere is provided a communications signal comprising computer-readablerepresentation of a hyperlink address according to the first aspect.

According to a further aspect of the present invention there is provideda computer system arranged to process signal comprisingcomputer-readable representation of a hyperlink address according to thefirst aspect.

According to a further aspect of the present invention there is provideda method of accessing a resource on a computerised network by means of acomputer-readable representation of a hyperlink address according to thefirst aspect.

According to a further aspect of the present invention there is provideda system arranged to access a resource on a computerised network bymeans of a computer-readable representation of a hyperlink addressaccording to the first aspect.

The invention also provides for a system which comprises one or moreinstances of apparatus embodying the present invention, together withother additional apparatus. The invention is also directed to methods bywhich the described apparatus operates and including method steps forcarrying out every function of the apparatus.

The invention is also directed to hyperlinks, methods, programs for acomputer, devices and systems substantially as described below and withreference to the accompanying drawings.

The preferred features may be combined as appropriate, as would beapparent to a skilled person, and may be combined with any of theaspects of the invention. Other advantages of the invention, beyond theexamples indicated above, will also be apparent to the person skilled inthe art.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to show how the invention may be carried into effect,embodiments of the invention are now described below by way of exampleonly and with reference to the accompanying figures in which:

FIG. 1 shows a schematic diagram of a known computer network;

FIG. 2 shows a schematic diagram of a computer network in accordancewith the present invention;

FIG. 3 shows examples of resource locators in accordance with thepresent invention;

FIG. 4 shows a schematic diagram of a system in accordance with thepresent invention;

FIG. 5 shows a flowchart of a method for accessing resources using ahyperlink according to the present invention;

FIG. 6 shows a flowchart of a method for inserting hyperlinks accordingto the present invention;

FIG. 7 shows a flowchart of a drag-and-drop method for insertinghyperlinks according to the present invention.

DETAILED DESCRIPTION OF INVENTION

Referring now to FIG. 2, a remote client 11 and a server 10 are providedwith a P2P client 112 and P2P server 1050 respectively. New forms ofresource locator 1142, 1143 are introduced which are identifiable asrequiring, for correct resolution, invocation of the new P2P client 112in the remote client. The new URL has at least one portion which isintended for interpretation, not on the remote client 11, but rather onthe server 10. A further portion intended for interpretation on theremote client 11 indicates upon which of the servers 10, 12 the otherportion is to be interpreted in much the same way as the domain nameportion of known URLs operates.

As result a new resource locator 1142 indicating access via HTTPrelative to server 10 would be passed to the local P2P client which inturn would forward the portion for remote resolution to the P2P server1050 running as local client 105 on server 10.

The indicated HTTP URL is then resolved in the known fashion to retrievewhichever web file—local 1030 or remote 12—is indicated, relative toserver 10. As a local client the P2P server can access files denoted byany form of URL formerly accessible to local client 104, including“file:// . . . ” URLs.

Referring now to FIG. 3, the mechanism is supported by an new form ofhyperlink address comprising an extended resource locator (or“hyperlink”), resource_locator, for use particularly in a distributedcomputer network environment. The resource locator comprises a peerlocator component 31 peer_locator, and a local resource locatorcomponent 32, local_resource_locator, the abstract syntax of which isdenoted as:

-   -   <resource_locator>::=<peer_locator><local_resource_locator>

The peer locator may be of a form similar to that for known resourcelocators (e.g. URL's), and comprises a peer scheme identifier 311,peer_scheme, and a peer identifier 312, peer_identifier, which uniquelyidentifies the peer of interest:

-   -   <peer_locator>::=<peer_scheme><peer_identifier>

The local resource locator, local_resource_locator, is provided toidentify the required resource relative to the peer entity denoted bythe peer locator. The local resource locator comprises both a resourcescheme identifier 321, resource_scheme, and a resource identifier 322,resource identifier:

-   -   <local_resource_locator>::=<resource_scheme><resource_identifier>

In combination the components of the peer locator are interpreted withreference to suitable address resolution mechanisms to provide access toresources local to a peer <peer_identifier> using accessscheme<peer_scheme>. For example, adopting a concrete syntax similar tothat commonly used for known URL's a peer locator may take the form:

-   -   p2p://net/servers/server1        in which “p2p” denotes the peer scheme (or protocol) and        “net/servers/server1” denotes the peer entity to be accessed.

Resolution of both the peer scheme component and the peer identifiercomponent may be performed using conventional name resolutiontechniques, whether centralised or distributed.

The local resource locator may take the form of any convention URL, forexample:

-   -   file:///C:/my_files/my_shared_file.html        so that a complete resource locator may take the form:    -   p2p://net/servers/server1/file:///C:/my_files/my_shared_file.html

Clearly the precise concrete syntax illustrated is not essential andother concrete syntaxes may be employed. However the use of a concretesyntax broadly in line with that for known URLs as exemplified abovewill minimise the changes necessary to existing resource locatorinterpretation software.

The local resource locator is resolved with respect to the resolutionrules associated with the peer entity identified by the peer locatorportion of the resource locator.

However the form of the local resource locator is not limited to file://. . . URLs: other known forms may also be employed including inparticular HTTP links 33 of the form “http:// . . . ”. In such cases thelocal resource locator may denote a resource local to the host denotedby the peer locator or remote to it. Interpretation of the HTTP URL isperformed in a convention fashion on the identified peer entity.Extended resource locators of this and similar forms may be used totunnel through firewalls so as to access, from a first network domain,files conventionally accessible only from within a second domain inwhich the identified peer entity is located. In this context the peerlocator may denote a peer domain rather than any specific peer host,provided that interpretation of the local resource locator portion isuniformly resolved across the peer domain.

In the cases above the local resource locator takes the form of aconventional URL as defined, for example, by the World-Wide Webconsortium (W3C). In such cases evaluation of the resource locator mayproceed in the known way, the results of the evaluation being passed tothe original requester by means of the protocol identified in the peerlocator scheme.

However the present invention is not limited to such simple cases andmay be extended to provide more complex resource locators in which thelocal resource locator may also take the form of a extended resourcelocator also having a peer locator component, so that the resourcelocator may take the recursive form:

-   -   <resource_locator>::=<peer_locator><local_resource_locator        >|<peer_locator><resource_locator>

In this way resolution of a resource locator may involve traversing ofmultiple peer entities identified by successive peer locators in theresource locator. The number of indirections supported is limited inprinciple only by any limit on the overall length of resource locator.

Resources accessed by these methods are typically web pages or otherfiles located on a peer entity. The peer is typically a device on acomputer network and such devices include—but are not limitedto—personal computer, laptop computers, servers, mobile telephonedevice, and personal digital assistants (PDAs). In a peer-to-peernetwork peer entities have broadly equal status and may act as servers(supplier of resources), clients (requesters of resources), or bothsimultaneously.

Whilst conventional URL's support local access of local files, forexample using resource locators of the form“file:///C:/my_files/my_shared_file.html”, remote entities are unable toaccess the named file using such a locator. However by providing thepeer locator component which identifies the peer relative to which thegiven resource locator may be successfully resolved enhanced accesscapabilities can be provided.

The use of an asynchronous pluggable protocol to implement the necessarysupport to handle the new resource locators provides a means for userstransparently to access hitherto inaccessible resources on apeer-to-peer network. Access to those hitherto inaccessible resources isreadily integrated with known access methods for resources in a simple,consistent, and easy to use manner.

Referring now to FIG. 4, the outline structure of a system capable ofimplementing the extended resource locators is shown.

The system 40 comprises conventional user software entities 41 (forexample Microsoft™ Windows™ programs 411 and editor Graphical UserInterfaces 412) above an APP 413. The upper layers make use of HTTPclient 421 and P2P client 422 software which control remote interactionswith other peer entities. At the lower layers P2P group and pipemanagement 431 and other infrastructure 441 is provided to provide theinterface to remote entities 45, whilst local file store 46 access iscontrolled by page indexing 432, file indexing 433 and local pages storemanagement 442 software.

Implementation of the constructions described above is relativelystraightforward and may be achieved in a many ways. The AsynchronousPluggable Protocol (APP) integrates the new resource locator scheme intoMicrosoft Windows so that Internet Explorer or any other Windowsapplication can link to wiki pages or access resources from the P2Pnetwork. This provides efficient and seamless access to resources(including wiki pages) on the peer to peer network.

Implementation of the APP of Windows is well documented, using theIIternetProtocol and IInternetProtocoInfo interfaces, the latter beingrequired to combine base and relative URL's correctly. A protocolhandler written in C++ makes use of the services provided by the P2Ppage and file management components. These are arranged to fetch theidentified page, file, or other resource over the P2P network and thenstream the results back to the Microsoft Internet Explorer or otherrequesting application. In one embodiment these components are writtenin Java, so that Direct Data Exchange (DDE) messages are used to handlecommunications between the protocol handler and these components. TheAPP also provides support for sending HTTP requests over the P2P networkusing an Open Source Apache HTTP client.

Referring now to FIG. 5 an example access method comprises a resourcelocator link being selected 511 by a user or user application. Theselected resource locator is passed 512 to IInternetProtocolInfo forparsing 5123, whereby the nature and location of the resource to beaccessed is determined.

Downloading proceeds 514 until all data has been received. The precisemethod and duration of the downloading, depending upon the nature of theresource accessed. IIInternetProtocol::Read and IinternetProtocolSinkare repeadedly invoked 522 until all data has been downloaded 523.IinternetProtocolSink, is invoked 521 to signify that access iscompleted.IInternetProtocol::LockRequest andIInternetProtocol::Terminate are then called 525 to complete theprocedure before invoking IInternetProtocol::Read to pass the requestedinformation back 526 to the requesting user application. Downloading iscompleted 527 by invoking IInternetProtocol::UnlockRequest.

Peer identifiers may take any of many forms:

-   -   Identifiers automatically generated by known techniques;    -   Individually assigned with manual intervention;    -   Use of email addresses (e.g. “p2p://bigal@myaddress.mynet”)

In the case of email addresses, resolution may involve associating acurrent “home” peer entity with each email address (e.g. the host id towhich email sent to the given address is normally delivered) and usingthis default destination as the current peer location of the user. Inthis way if a user relocates to a new file server host and emaildelivery point resolution of resource locators will automatically“follow” the user to the new host.

In a system supporting resource locators a WYSIWYG editor may also beprovided. In one embodiment this may take the form of an extension toMicrosoft Internet Explorer or other web browser/editor. A browserhelper object is used to detect when an object comprising a resourcelocator as described above is loaded using the APP. This then activatesan editor having a toolbar. The toolbar provides buttons and underlyingfunctionality to create a new page, and search or browse for an existingpage or shared resource. This may, for example, be implemented usingappropriate Java GUI's using DDE messages though other implementationsmay also be used. The toolbar may either be shown by default or providedas a user-selectable option.

While editing a page, normal formatting options may be provided butadditional functionality related to the new resource locators describedabove is also provided. In particular references to local files whichare inserted in the page being edited are automatically modified to takethe form of resource locators comprising a peer-to-peer locator. So forexample a local hyperlink such as:

-   -   file:///C:/my_images/my_shared_image.jpg        may be replaced by a resource locator of the form:    -   p2p://net/servers/server1/file:///C:/my_images/my_shared_image.jpg

This may be achieved in any one of many ways as would be apparent to theperson skilled in art, including:

-   -   an icon associated with of the file to be referenced may be        dragged-and-dropped into the editor interface and the hyperlink        automatically generated comprising a peer locator upon        insertion;    -   the icon may be dragged-and-dropped to insert a conventional        local “file://” URL and conversion to the new peer-locator form        only performed upon explicit request by the user (for example by        means of an option on a drop-down menu selectable with respect        to the newly inserted hyperlink);    -   A conventional URL may be inserted giving a location relative to        the local host as the page is constructed and converted        afterwards to comprise a peer locator as a “batch” job applied        to all identified references within the file (for example        automatically when such a page is emailed to a third party).

Referring now to FIG. 6 one such method comprises a user selecting 611“insert image” from a suitable on-screen menu. A Dynamic HTML (DHTML)dialog box is opened 612 which allows the user to select and insert animage of interest. Upon saving 613 the resulting page the page body isscanned 614 for resource locators. Selected resource locators (e.g.those referring specifically to local files, or all those relating toimages) are identified within the page and replaced 615 with acorresponding peer-to-peer resource locator.

The APP is responsible for loading the inserted images when the pageitself is loaded. Links for files are implemented in a similar manner,except that a file-chooser dialog box may be opened to select a file towhich to link. Links to web pages are also implemented in this mannerusing a DHTML insert link dialog. Links to web pages can take one of anumber of forms: the conventional “http:// . . . ” form if the web pageis available on a remotely accessible intemet site or web server, or“p2p://<peer_identifier>/http:// . . . ” if the web page is onlyavailable on a local intranet or web server and access is to be providedto a user unable to access the local intranet or web server.

Links to wiki pages use Java GUI's, via DDE, to select the wiki page tobe linked to. The link is then inserted into the page as a link of theform <peer_locator><page_name>. Various concrete syntaxes could beemployed in practice to denote the page.

Referring now to FIG. 7 the drag-and-drop approach may be implemented bycatching 711 the resultant BeforeNavigate Internet Explorer IWebBrowser2event, cancelling the navigation 712 and inserting 713 an appropriate“p2p:// . . . ” link to the resource dropped on the browser window.

If the user does not select 714 visible text with which to associate thehyperlink to be inserted, then the drag-and-drop editor mayautomatically insert suitable text 715 (for example the textual form ofthe resource locator). In either case completion of the hyperlinkinsertion follows 716.

Conventional remotely-usable resource locators (e.g.http://myhttpfile.htm) may, but need not, be extended to include a peerlocator According to whether they are to be made accessible beyond thepresent domain as described above.

Many other software tools may also be provided to operate upon suchpeer-to-peer resource locators including editors supporting insertion ofhyperlinks in textual form (rather than dragging and dropping icons) andtools arranged to update pages containing resource locators as and whenpeer identifiers are modified.

Whilst the embodiments described above have been based upon a specificoperating system and applications programs (e.g. browsers) it will beapparent to the person skilled in the art that other embodimentsemploying other operating system and applications programs are envisagedwithin the scope of the present invention.

Furthermore it will be understood that whilst the embodiments describedrefer to “local” and “remote” clients, the concept is not actuallylimited by the physical location of those clients relative to each otheror to the files to be accessed. Rather the principle may be applied toany situation in which a first client has access via file managementsoftware to files typically not accessible over the web by currentmethods. The files may be resident on the same host machine as theclient, or may be on a physically remote server. The second (“remote”)client to whom access is granted by means of the new form of hyperlinkmay in principle be located either remotely as described above or may bephysically located on the same host as the files to be accessed. Howeverthe second client need not have direct access to the non-webfilesdirectly accessible to the first client in order to access them by meansof the extended resource locators described above.

Any range or device value given herein may be extended or alteredwithout losing the effect sought, as will be apparent to the skilledperson for an understanding of the teachings herein.

The invention claimed is:
 1. A computer-readable memory device having instructions stored thereon, wherein the instructions are configured to cause at least one device to perform operations comprising: generating a hyperlink comprising a first address portion and a second address portion according to a selection of an icon from a drag-and-drop user interface, wherein the first address portion identifies a network address of the local server application and the second address portion addresses a location in a memory system of the at least one device where the file is accessible, wherein the icon identifies the file, and wherein the hyperlink is automatically generated and includes concatenating the first address portion with the second address portion; receiving a file request at a local server application in the at least one device, wherein the file request is received from a client requesting a file, wherein the file request comprises the first address portion and the second address portion; analyzing the second address portion to identify a type of memory system access that is requested by the file request; retrieving the file from the location in the memory system with the local server application or with a hypertext transfer protocol (HTTP) server application in the at least one device based on the type of memory system access requested by the file request; and transmitting, by the local server application in the at least one device, the file to the client.
 2. The computer-readable memory device according to claim 1, wherein the first address portion further identifies a network domain associated with the at least one device, and wherein the client is associated with a different network domain.
 3. The computer-readable memory device according to claim 2, wherein the second address portion identifies an address of the memory system in the network domain.
 4. The computer-readable memory device according to claim 2, wherein the file is directly accessible from the network domain based on the second address portion.
 5. The computer-readable memory device according to claim 1, wherein the first address portion is analyzed by the client to identify the network address of the local server application.
 6. The computer-readable memory device according to claim 1, wherein the operations further comprise transferring the file request across multiple peer entities identified by successive hypertext transfer protocol (HTTP) addresses in the file request.
 7. An apparatus, comprising: means for generating a hyperlink comprising a first address portion and a second address portion according to a selection of an icon from a drag-and-drop user interface, wherein the first address portion identifies a network address of the local server application in the apparatus and the second address portion includes an address of a memory device in the apparatus where a file resides, and wherein the second address portion is separately denoted in the file request from the first address portion, wherein the icon identifies the file, and wherein the hyperlink is automatically generated and includes concatenating the first address portion with the second address portion; means for receiving a file request comprising the first address portion and the second address portion; means for analyzing the second address portion to identify a type of memory system access that is requested by the file request; and means for retrieving the file from the memory device identified by the second address portion with the local server application in the apparatus or with a hypertext transfer protocol (HTTP) server application in the apparatus based on the type of memory system access requested by the file request. 